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(57) Abstract: An embodiment of the invention provides for a system, method, apparatus, and computer program product for deWce, 
user, and/or transaction verification, authentication, and non-repudiation. Wireless application (154) captures and utilizes biometric 
data (253, 279, 332) from user (i 01) in possession of mobile phone. PDA, or other portable computer (102). Information appliance 
(1 10) authenticates de\ice (102) and/or user (101) to reduce or eliminate likelihood that transaction will be repudiated. Transaction 
authentication and non-repudiation (344, 356, 205) is applied to all manner of commerce including purchase and sale of products 
and services, banking, investment and other financial transactions (106), as well as in personal transaction not directly involving 
commerce. Authentication and non -repudiation occurs over a wireless or end-to-end wired network of interconnected computers 
(155, 103, 104). 
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Field of Invention 

This invention pertains generally to device, user, and transaction verification and 
authentication systems and methods; and more particularly to device, user, and 
transaction verification, authentication, and non-repudiation system dnd method for 
10 mobile wireless applications that capture and utilize biometric data for transaction 
verification and authentication. 



BACKGROUND 

Heretofore, mobile Internet or other network-based transactions have been 
15 susceptible to security, identity fi^ud, and privacy risks. Stopping repudiation for a 
financial or other transactions on the basis that a person other than a person authorized 
to make the transaction actually made the transaction, have also presented significant 
concerns and costs to merchants and financial institutions. There has also been a desire 
to eliminate any need for entry of character based passwords on mobile device keypads. 
20 particularly where security requirements would impose characters in excess of a 
reasonable number of characters entered on such device keypad, such as for example 
eight character strings in order to provide to provide a desired security level. This is 
especially true for mobile telephones where there is a less than one-to-one ratio of keys 

to characters or numbers. 
25 There has also been desirability of improving a user experience so that the user 

has confidence that's the transaction is being handled properly and in a professional 
manner without undue security risks. Improving the interface for the user, independent 
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S of any added security, is also desirable so as to promote use of such mobile transaction 
systems. 

In addition to or instead of Internet based mobile access, there is also desirability 
of providing protected access to content not otherwise publicly available with 
appropriate concern paid to controlling access to authorized parties in a manner that 
10 protects such non-public content (for example, private databases) or networks. For 
example, protected access to many intranet or extranet corporate database is desirable 
where a data center is desirable to support mobile professionals needing to retrieve 
information from, or communicate information to, such private databases, data systems, 
or networks. 

IS Increasing the level of security to a level such that banks and other financial 

institutions that have or support credit card, debit card, or other financial instruments or 
transactions, have sufficient confidence in the access mechanism that they would be 
inclined to eliminate or reduce any customary "card not present" charges to online 
merchants, and even more desirably, to charge only the same rate for mobile Internet 

20 based transactions as charged when a physical card or other identification, 
authentication, or validation instrument is physically present is also highly desirable. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a diagrammatic illustration showing an embodiment of an 
25 infrastructure enabling secure mobile e-commerce using wireless BioPDA™ and having 
transaction non-repudiation features. 
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5 FIG. 2 is a diagrammatic illustration showing an embodiment of the interaction 

and communication flow in a wireless BioPDA^^ implementation including 

authentication process. 

FIG. 3 is a diagrammatic illustration showing an embodiment of an in-house 
intranet/extranet (non-Internet) implementation with optional remote Internet 
10 connectivity to the intranet/entranet. 

FIG. 4 is a diagrammatic illustration showing an embodiment of an Internet 
based transaction authentication and non-repudiation service. 

FIG. 5 is a diagrammatic illustration showing an embodiment of a wireless 
Password (PWD) Bank implementation. 
1 5 FIG. 6 is a diagrammatic illustration showing an embodiment of the interaction 

and communication flow in a wireless Password (PWD) Bank implementation. 

FIG. 7 is a diagrammatic illustration showing an embodiment of the data 
structure of an X.509 type ID certificate with exemplary private biometric extension 
(PBE). 

20 FIG. 8 is a diagrammatic illustration showing an embodiment of the data 

structure for an exemplary Biometric Attribute Certificate (BAG) used in conjunction 
with an X.509 type Certificate. 

FIG. 9 is a diagrammatic illustration showing an embodiment of a transaction 

token. 

25 
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5 SUMMARY 

Aspects of the invention provide system, method, apparatus, and computer 
program and computer program product pertaining generally to device, user, and 
transaction verification, authentication, and non-repudiation. It includes a mobile 
wireless application that captures and utilizes biometric data from a user in possession 

10 of a mobile phone, PDA, or other portable computer or information appliance that 
verifies the device and/or user so that the transaction may be verified and authenticated 
in a manner than substantially reduces or eliminates the likelihood that the transaction 
will be repudiated by the person to whom the transaction is attributed. Transaction, 
authentication and non-repudiation features may advantageously be applied to all 

1 5 manner of commerce including the purchase and sale of products and services, banking, 
investment and other financial transactions, as well as in personal transaction not 
directly involving conmierce in a conventional sense but where verification of identity 
is important. 

In another aspect, the invention provides for authentication over a wireless 
20 network of interconnected computers or information appliances, such as the wireless 
Intemet or a wireless device connected to the Internet. In another aspect, the invention 
provides end-to-end wired or wireless authentication infirastracture. In still another 
aspect, the invention provides a comprehensive network-based authentication system, 
method, device, and computer program and computer program product that provides 
25 non-repudiation for financial and other transactions on the mobile Intemet or other 
network. In even still another aspect, the invention provides a business method and 
operating model for a transaction authentication and non-repudiation service. 
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In one embodiment, the invention provides a transaction authentication and non- 
repudiation system including a transaction server coupled with or intermittently 
coupleable to other information processing devices over a network, where the 
transaction server includes a database or is coupleable to a database storing at least one 
user credential and at least one transaction record, the transaction server including a 
processor and a memory coupled to the processor for executing transaction 
authentication instructions. 



DETAILED DESCRIFOON 

In one aspect, the invention provides system, method, apparatus, and computer 
15 program product pertaining generally to device, user, and transaction verification, 
authentication, and non-repudiation. It is particularly well suited for implementation as 
a mobile wireless application (or applications) that captures and utilizes biometric data 
from a user in possession of a mobile phone, PDA, or other portable computer or 
information appliance that verifies the device and/or user identity so that the transaction 
20 may be verified and authenticated in a manner than substantially reduces or eUminates 
the likelihood that the transaction will be repudiated by the person to whom the 
transaction is attributed. Such transaction non-repudiation feature is desirable for many 
types of commercial and financial transactions but is particularly usefiil for financial 
transaction, such as stock market or securities purchases or sales, where a user may be 
25 tempted to repudiate a buy or sell order to their financial advantage and to the detriment 
of the broker or financial institution performing the transaction on behalf of the user. 
Such transaction authentication and non-repudiation features may also clearly be 
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5 applied to all manner of commerce, including but not limited to the purchase and sale of 
products and services, as well as in personal transaction not directly involving 
commerce in a conventional sense but where verification of identity is important. 

In another aspect, the invention provides for authentication over a wireless 
network of interconnected computers or information appliances, such as the wireless 

10 Internet. In another aspect, the invention provides end-to-end wired or wireless 
authentication infi^tructure. In still another aspect, the invention provides a 
comprehensive network-based authentication system, method, device, and computer 
program and computer program product that provides non-repudiation for financial and 
other transactions on the mobile Internet. 

15 Advantageously, in many of the inventive embodiments these and other 

inventive features and aspects are readily adapted to interoperate with existing device : 
manufacturer's mobile telephone, Personal Data Assistants (PDAs), and computer 
products (such as for example, products made by Nokia, Ericsson, Acer, IBM, Palm, 
RIM, Handspring, Compaq), network operators (such as for example, Vodafone, NTT, 

20 Verizon, and AT&T), network platforms (such as for example, Phone.com, Inktomi, 
and Microsoft), and security providers (such as for example, Certicom, RS A, Verisign, 
Thawte, Baltimore, and Velocit-e). Furthermore, such features and aspects are also 
compatible with the needs and infrastructure of financial institutions (such as for 
example, Barclays Bank, VISA, Credit Lyonnaisse, and the like) as well as with Smart 

25 Cards/Wallets (such as smart cards and wallets made or supplied by G&D, Gemplus, 
Passport, and others). While compatibility and interoperability is advantageously 
maintained relative to many embodiments, it will be appreciated that other 
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5 embodiments of the invention may not provide compatibility with legacy systems as the 
technology evolves so as to provide advanced features. 

In a preferred embodiment of the invention, system capabilities are extended 
using fingerprint bio-certification technology. In one embodiment, a standard X.509 
certification is used. In another embodiment, a higher grade extended X.509 
10 certification having biometric attributes is provided (referred to here as a BioCert). In 
other embodiments, information analogous to that provided with an X.509 type 
certificate is provided but the X.509 certificate itself is not required. Any of these 
certifications, but particularly the enhanced certification having biometric attributes, 
will (or are expected to) enable merchants to qualifying for reduced "card present" 
1 5 transaction rates from the card issuing organization for credit card, debit card, and the 
like transactions. The system method of the present invention therefore provide a 
number of improvements and capabilities beyond those presently available for mobile 
transactions. In one aspect, the invention provides an improved user experience. In 
another aspect, the invention provides biometric extensions to standard certificate 
20 infrastructure, and in particular biometric extensions to standard X.509v3 certificate 
infrastructure, as well as new certificate infrastructure incorporating biometric data. In 
yet another aspect the invention is biometric agnostic. In a further aspect, inventive 
system and method build on an expanded existing Public Key Infrastructure (PKI). In 
still another aspect, the inventive system and method provide for small or thin client 
25 side component footprints that interoperate and otherwise satisfying memory and 
processing limitations imposed by mobile phones, PDAs, and other typically thin 
mobile information appliances. In a further aspect, embodiments of the invention 
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5 provide optimized authentication and electronic signing (eSigning) protocols that work 
fast and reliably even over typically slow or limited connections available with wireless 
technologies. In yet another aspect, the invention provides extendable storage of user 
data, such as through the use of XML and/or extensions thereof, including but not 
limited to for example, extendable storage for a user's stock portfolio, or the like 
10 information. In yet a further aspect, the system and method provide for scalability and 
support for LDAP and UNIX-based Web servers, such as for example Apache, or the 
like. 

Having now described some features and advantageous aspects of the invention, 
attention is now directed to a description of particular exemplary system configurations 
1 5 and methodological procedures which assist in understanding the manner in which the 
invention may be deployed and used. 

Overview of Embodiment of System Infrastructure 

An overview of one embodiment of the inventive system is now described 

20 relative to FIG. 1 . An access device, preferably a hand-held device or portable device 
1 02, such as a mobile phone, smartphone, personal data assistant (PDA), hybrid device 
such as an information appliance or portable computer/communication device having 
wireless communication capability is connected or intermittently connectable to a 
network 1 04 of computers or other infomiation processing devices or appliances, such 

25 as the Internet. The network 104 may for example be, but is not limited to a network 
supporting communication using WML, HTML, CHTML, xHTML, or combination, 
variant, or extension thereof. Furthermore, while wireless communication takes 
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5 advantage of the features of the invention and provides a particularly advantageous 
operation, it will be appreciated that the invention is also operable with wired 
communication infrastructure. 

In an exemplary configuration, the portable device 102 comprises a wireless 
BioPDA, where communication is achieved using radio-frequency conununication 
1 0 techniques such as are well known in the art. In this embodiment, described relative to 
FIG. 1, a Compaq iPaq PDA running the Microsoft Pocket PC operating system (for 
example the iPaq H3600 series running Pocket PC version 3.0 or 2002) with a wireless 
modem (as are known in the art) is used as the base user device platform within portable 
mobile device 102. A PDA 102, such as the iPaq Pocket PC (for example, model 
1 5 H3600), palm, Sony Clie™, or handspring devices represent one type of mobile device 
1 02. A fingerprint sensor, scanner, or other biometric capture device 1 5 1 is provided as 
an add-on component. Altematively, a sensor scanner or other biometric capture device 
151 may be provided internal to device 102 and be exposed through a surface or 
aperture on the surface of the device. For example, the compact flash adapter or PC 
20 card adapter with its ability to mechanically and electronically attach to and couple with 
the iPaq device 102 via a slot and coimection may be used to attach the fingerprint 
sensor component. An add-on peripheral may similarly be attached to a communication 
infrastructure on a mobile phone. Client Agent Applet 152 for the Windows CE or 
Packet PC Browser (such as GoWeb from GoAmerica, Microsoft Explorer, or 
25 Microsoft MobileBrowser) and driver or drivers are also provided. Compatible 
browsers for the Pahn Operating System (PALM OS), Linux, or other platforms may 
altematively be provided. An inventive Client Agent Applet 152 or application 
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S program is also used and may advantageously use a X.S09v3 based certificate, such as 
the X.509v3 certificate with private "bio" extensions (PBE). 

An embodiment of such a wireless biometric enabled PDA (BioPDA™) 102 
uses a biometric sensor 151 (such as for example, a fingerprint sensor, a retinal scan 
sensor, a voice- or speech-based sensor, or any other biometric sensor), and computer 

10 code software/firmware Bioauthentication Applet 152 operative with the biometric 
sensor in the device 1 02. Note that the Compaq iPaq H3600 series devices (such as for 
example, the H3635, H3650, H3660, H3670, or H3700 or H3800 series) includes a 
microphone and voice recording capability that maybe used where the biometric is or 
includes a voice or speech biometric identification or recognition parameter Device 

15 102 includes a wireless modem as an integral component or as an add-on device (such 
as a compact flash or PC card based wireless modem), or wireless telephone coupled to 
the PDA via serial, infixed (IRDA), or other communication or coupling means. 
Various wireless communication technologies including modem based communications 
for cellular telephones, PDAs, and mobile commimication are known in the art and 

20 therefore are not described in greater detail herein. 

With further reference to FIG. 1, BioPDA™ 102 communicates with a wireless 
receiver station 155, which in turn communicates to a wireless Internet gateway 1 56 via 
available wired or wireless communication channels or other means 103, which may, 
for example, comprise any conventional telephone line, satellite link, cable, wire or the 

25 like, as are known in the art. In some embodiments, wireless receiver station 155 and 
wireless Intemet Gateway 156 are combined. Wireless Internet gateway 156 in turn 
couples to the Transaction Server (TS) 110 via Intemet 104. Some portions of this 
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5 description refer to an "iControl" version or embodiment of an aspect of the invention. 
Such "IControl" references are made relative to certain commercial developments and 
design prototypes being undertaken by IControl Transactions, Inc., the Assignee of this 
invention. For example, reference is made to an IControl Transaction Server (ICTS) 
which is a particular embodiment of the Transaction Server (TS) 110. The wireless 
10 BioPDA system configuration of FIG. 1 also includes or inter-operates with a 
Business/Merchant Web Server (Biz/Merchant) BWS 106. A Server Agent (e.g. 
IControl Server Agent) 107 is advantageously provided with BWS 106, and desirably 
includes a Server Agent Toolkit (SAT) 109 to facilitate integration, testing, and 
maintenance. The Server Agent 107 and Server Agent Toolkit 109 are described in 
1 5 further detail elsewhere in this specification. 

A demonstration web server site may optionally be provided (shown in some 
embodiments) to simulate an on-line business web server, such as for example an on- 
line stock trader. In such demonstration configurations, the particular Web application 
(such as a demonstration online stock trader) will not necessarily be part of the actual 
20 system. 

In practice, an entity desirous of setting up and interfacing their web server with 
the inventive system and method, uses features, capabilities, and software provided with 
the Server Agent Toolkit 109. The inventive Transaction Server (TS or ICTS) and 
Server Agent Toolkit (SAT) are provided to a business, merchant, organization, 
25 individual, or other entity so that an authentication and non-repudiation compatible 
website may be constructed and interoperate with other inventive system components 
and methodological procedures. The Business Website server (or demonstration site) 
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5 106 is coupled to the transaction server 110 and wireless Internet gateway 156 via 
Internet 104. 

Direct or other non-Internet connection may alternatively be provided or the 
BWS 106 may be co-located with the transaction server 1 10. In one embodiment, the 
business web site server 106 is or includes a demonstration site that* replaces a real 

10 merchant§s website in actual system implementations, however, this is not the typical 
configuration. The transaction server such as ICTS 110 advantageously includes or is 
coupled to a database or databases, such as the LDAP databases 1 13, 1 14, storing user 
credentials, business data (such as XML documents or documents or data in other 
form), and transaction records. 

15 A business or merchant computer configured as a Web server 106 is also 

connectable over a conmiunication link or channel 103 to the Internet 104 as well as 
optionally to financial/banking/credit card infiastmcture or organization 1 08. This latter 
connection to the infrastructure or organization 108 may be made by an Internet 
connection or by other shared or dedicated communication link, such as for example, a 

20 direct analog telephone connection, dedicated phone line, satellite, cable or the like. 
Characteristics of business or merchant Web server 106 are generally conventional in 
nature except for the components provided to Internet with the transaction server, and as 
numerous server configurations are known in the art, are not described here in greater 
detail. 

25 An additional server, such as an Internet Web Server configured as the 

Transaction Server 1 1 0 when the network is the Internet, configured to provide at least 
some of the desired security and authentication features is also connected or connectable 
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5 todevicel02andWebserverl06viaIntemetl04. one embodimenUhis additional 
server 110 is referred to as the Internet Web Server (IWS) as a more specific Input 
in^plementation of a transaction server. It is noted that although multiple servers are 
described in which different aspects of the transaction take place on different servers, 
such logically diverse or geographically diverse processing is not required in all 
,0 embodiments, and that many of the functions and/or operations may be processed in 
fewer servers or even in a single server in other embodiments. 

Transaction server 110 includes a computer of conventional , type having a 
processor or CPU, a memory coupled to processor for storing instructions and data 
during execution of computer programs, mass storage device such as a hard disk drive, 
15 and other input/output and peripheral components that support the data, content, and 
security or certificate transactions provided by server 110. In addition to these 
conventional components, serverllOadvantageously includes one or moredatabaseor 

other storage devices or subsystems storing data using Lightweight Directory Access 

Protocol(LDAP)113,ll4. 
20 The Client side components include a client agent 154 (in one embodiment, 

referred to as the IControl Chent Agent) that comprises a software application (such as 
for example a computer program software or firmware application written in C, C^, 
Java.oranyotherapplicationprogramminglanguagesuitableforaparticulardeviceor 

devices). Code or program libraries that operate on the user§s mobile device (for 
25 example, PDA. mobile phone, Smartphone. or other intelligent mobile information 
appliance) may also typically be utilized. 

The fiinctionality provided by any particular client agent 154 may sometimesbe 
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5 dependent upon the particular client characteristics, however, it may generally provide 
at least some and in at least one embodiment of the invention, all of the following 
functions, some of which functions are optional but advantageously provided: (i) local 
(on client device) biometric authentication, (ii) support server-based biometric 
authentication, (iii) local digital transaction signing, (iv) Local audit-trails and logging, 

10 (v) client components for server based notarization, (vi) client components for server 
based audit-trails and logging capabilities, and (vii) local biometric authentication for 
access control to users PKI private keys. Each of these client agent based functions is 
now described in greater detail. 

Client agent 154 provides local (that is on user client device 102) biometric 

15 authentication of a user (or of an attempted user) against a local database of users and 
their biometric samples or against a local database of Biocertificates. Such an 
authentication may for example be initiated by a Web Server or Web application, such 
as by BWS 106, in order verify the identity of a user and/or device attempting access to 
allow access to a protected resource on that Web Server. 

20 Client agent 1 54 may also provide the necessary client components for server 

based biometric authentication of a user against a server side database of users and their 
biometric samples or against a server side database of Biocertificates. Such an 
authentication may also or alternatively be initiated by a Web Server or Web application 
in order verify the identity of a user to allow access to a protected resource on this Web 

25 Server. 

Client agent 154 may further provide local digital signing of transactions, 
documents or other forms of electronic data involving biometric authentication of the 
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5 signer (which may be server based or local based), the signer§s Biocertificate(s) and/or 
private key(s). This may be based on RS A. elliptic curve or other techniques known in 
the art. 

Client agent 154 may in addition provide local audit-trails and/or logging 
capabilities of performed biometric authentications and digital signatures such asmy be 
10 useful in order to provide non-repudiation or documentary evidence to support non- 
repudiation, such as may be desired during a post-transaction legal proceeding. 

Client agent 154 may yet further provide any necessary or desired client 
components for server-based notarization of a local digital signature (as described 
above) or biometric authentication. 
1 5 Client agent 1 54 may further any necessary client components for server based 

audit-trails and logging capabilities of performed biometric authentications and digital 
signatures in order to provide non-repudiation or documentary evidence to support non- 
repudiation such as may be desired during a post-transaction legal proceeding. 

Finally, client agent 154 may provide local biometric authentication for access 
20 control to users PKI private keys stored on the client device. 

With further reference to FIG. 1, attention to some characteristics of an 
exemplary Transaction Server (TS) 1 10 such as the ICTS 1 10 or other Internet Web 
Server (IWS) configured as a transaction server. In one aspect, the transaction server 
may be considered to be one or more software application program(s) that reside on a 
25 computer web server and provides the server side capabilities for authentication 
services, digital signing services, archiving services, and/or other transaction non- 
repudiation services. It can be physically and logically located within the customer§s 
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5 premise, behind a firewall of the customer (such as for example, where the merchants 
web server resides) or it can be hosted by a trusted or otherwise independent third party 
(such as for example, a network operator, bank, system integrator, or the like) and used 
as a transaction non-repudiation application service provider (ASP). Depending on the 
particular implementation, the transaction server and transaction server application 

1 0 program(s) provides one or any combination of the following functions: (i) server based 
biometric authentication of a user, (ii) server based notarization of a client side digital 
signature, (iii) server based audit-trails and logging, (iv) interface to certificate 
authorities for enrollment of new users, and (v) interface to certificate authorities and 
certificate revocation lists for biometric authentication. Each of these transaction server 

IS based functions is now described in greater detail. 

The transaction server application program or programs (recall that the . 
transaction functions may be provided by possibly geographically diverse computer 
systems or components) provides any necessary server components for server based 
biometric authentication of a user against a server-side database of users and their 

20 biometric samples or against a server-side database of Biocertificates. Such an 
authentication might be initiated by a Web Server or Web supplication in order verify the 
identity of a user to allow access to a protected resource on this Web Server. 

The transaction server 110 may also provide any necessary server components 
for server based notarization of a client side digital signature (see above) or biometric 

25 authentication. It may also provide any necessary server components for server based 
audit-trails and logging capabilities of performed biometric authentications and digital 
signatures in order to provide non-repudiation. 
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5 The transaction server application program may also provide an interface to one 

or more Certificate Authorities in order to generate a user§s Biocertificate in support of 
the enrollment of new users. It may further provide interface to one or more Certificate 
Authorities an/or certificate revocation lists to provide up-to-date information on the 
validity, revocation status, or other information regarding a used Biocertificate if it is 
1 0 based on a X.509 certificates, thereby supporting biometric authentication. 

Finally, the third major component is the business or merchants web server 
(Biz/merchant web server) 106 including server agent 107, where business or merchant 
refers to a broad class of entities providing, retail or wholesale goods and/or services 
independent of whether such goods or services are provided fi-ee or for a fee, and 
15 including all fmancial, banking, brokerage, infonnation, sales, decision, proxy, or the 

like goods and services. 

In one embodiment, the web server includes a toolkit (also referred to as a 
software development kit or SDK) that provides any necessary applets and libraries for 
the integration of the mobile wireless network-based transaction and non-repudiation 
20 services (such as the authentication, transaction signing, non-repudiation services) into 
Web Sites or Web applications. Depending on the implementation, the server agent 1 07 
provides one or any combination of following functions: (i) an interface between the 
mobile wireless network-based ti:ansaction and non-repudiation services and the 
application requiring such services, and (ii) a routing interface that provides a 
25 communication relay between tiie client agent 154 and the transaction server 1 10. 

Addressing each of these server agent functions in fiirther detail, the server 
agent 1 07 provides the interface between the mobile wireless network-based transaction 
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5 and non-rq^udiation services and the application (for example, the Web Site, Web 
Application or other applications) requiring such services. This interface may be 
implemented as function calls to libraries provided, rule-based Web (http) proxies that 
trigger functionality based on the analyses of passing messages/packets, embedded 
objects in html pages (such as ActiveX or Java Servelets), as IS API or NSAPI filters, as 

1 0 code in active server (ASP) or dynamic HTML pages, as Java applications, or in other 
ways as are known in the art. This interface provides the functionality for the integration 
of enrollment and maintenance of users, local or server side biometric authentication, 
and logging and auditing as well as digital biometric signing into the application 
requiring of such services. The application requiring such services can also define 

1 5 parameters for invoked function: for example, required authentication method (e.g. what 
type(s) of biometric technology such as fingerprint, voice, face, signature, or the like 
should be used), required score or degree of match of the used authentication methods, 
and/or required enrollment method, and the like. 

The server agent "routing" interface provides a communication relay between the 

20 client agent and the transaction server. In one embodiment, all communication between 
the client agent 1 54 and the transaction server is routed through the server agent 1 07. In 
another implementation the client agent 1 54 communicates directly with the transaction 
server 1 10. In yet another embodiment the client agent 154 commimicates directly as 
well as through the routing interface of the Server Agent 107 with the transaction server 

25 110. 

Note therefore that in at least one embodiment of the inventive system and method, 
in order to perform biometric authentication (local or server side) or digital biometric 
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5 signing (local or server side) including server side notarization, the client agent 1 54 has 
to communicate with the transaction server 1 1 0. In one implementation the client agent 
communicates directly with the transaction server, while in an alternative embodiment, 
the communication between cHent agent and transaction server flows through a relay 
function of the Server Agent 107. These communication methods and pathways are 
1 0 described in greater detail elsewhere in this description. 

With reference to the embodiment illustrated in FIG. 2, aspects of 
communications that occur among and between system components and process as well 
as between system components and processes and external ones are now described. In a 
first embodiment, illustrated in FIG. 2A. the client agent communicates directly with the 
15 transaction server (that is without an intervening server agent). In a second or 
alternative embodiment, illustrated in FIG. 2B, the communication between the client 
agent and the transaction server flows through a relay function of a server agent 107. 
Each of these alternative embodiments are now further described relative to the figures. 
Either of these configurations may further involve data, information, tokens, packets, or 
20 the like flowing through third party or other intermediate servers as one known in the 
Internet arts. In each of these diagrams, dashed or broken lines identify an IControl 
Communication ("control communication") while solid or un-broken lines identify 
logical WAP/HTTP connections ("logical connection"), typically built upon an 

underlying TCP/IP protocol. 
25 With reference to FIG. 2A, in this communication flow, a user first perfonns a 

transaction over a logical connection that is protected by the inventive method (such as 
the IContrt)! method) thereby causing a communication between the client agent 102 
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S (such as the bioauthentication applet) executing on the client device and 
business/merchant server agent 106 executing on the business/merchant web server 
(Step 341 ). Note that this communication normally occurs over a logical WAP/HTTP 
. connection as indicated by the solid line in the drawing. Next, the bioauthentication 
applet on the client device is initiated (Step 342) by the server agent, such that a 

1 0 biometric sample is collected by the client device (such as a fingerprint sample) and 
compared against stored authorized biometric indicia resulting in a local match or local 
non-match. This communication normally occurs as a system (e.g. IControl) 
communication as indicated by the broken or dashed line in the drawing. A first non- 
match may result in a predetemiined number of retries. A* bi-directional 

15 challenge/response authentication after local match is performed between the client 
agent and the transaction server (Step 343). If the authentication is successful, the 
transaction server sends a signed authentication/transaction token to the client agent 
(Step 344). The client agent then forwards the signed authentication/transaction token 
to the server agent on the business/merchant web site (Step 345). The Server agent and 

20 . the transaction server communicate via request and response to exchange user data 
(such as in the form of an XML document) with authentication/transaction token 
(Step 347). Note that in one embodiment, the transaction server includes a LDAP-based 
database including user credential data such as business data in the form of XML or 
other documents or data and transaction records. 

25 With reference to FIG. 2B, similar functionality is provided, however, the 

communication between the client agent and the transaction server flows through a relay 
function of a server agent. In this embodiment, optionally, a SSL/TLS session is 
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5 established (Step 351). Next, but also optionally, user authentication is performed bi- 
directionally based on the inventive IControl Non-Repudiation Infrastructure (ICNRI) 
according to the senders security policy (Step 352). These first two steps are optional 
and are not required in all embodiments, for example, they are not required where 
communication between the client agent and the business/merchant web server is 
1 0 already present or provided by other means. 

The user then requests a transaction protected by the inventive method, usually 
according to security policy (Step 353). The client agent program applet is initiated and 
is downloaded prior to initiation if not already present on the client device (Step 354). 
A bi-directional challenge/response authentication procedure is perfomied between the 
1 5 client agent and the transaction server via the server agent applet (that is indirectly) after 
local biometric match is performed on the client (Step 355). Note that this step involves 
a communication between the server agent and the transaction server to relay the 
challenge/response (C/R) from the client agent to the transaction server (ICTS). This 
step (Step 355) therefore includes a client agent to server agent component (step 355a) 
20 and a server agent to transaction server component (step 355b). A copy of the signed 
Authentication/transaction token is forwarded to the client agent (Step 356). first from 
the transaction server sending a signed authentication/transaction token to the 
business/merchant web site server (step 356a), and the business/merchant web site 
server forwarding the or a copy of the signed authentication/transaction token to the 
25 client agent (Step 356b). It is noted that in yet another embodiment, the transaction 
server may be placed in the same network as the business/merchant web server. 

An in-house embodiment of the invention is illustrated in FIG. 3. an Internet 
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5 web server 110 configured as a transaction server 110 and having a coupled or 
associated database 113, such as an SQULDAP database, and storing user credentials in 
a database 1 1 5, and BWS 1 06 are coupled to each other and to other components of the 
system via a network, such as an intranet or extranet 1 29. End user devices 1 02, such as 
mobile phones, PDA's, notebook computers, or various hand-held devices also connect 

10 to the Internet/extranet 129 for access. Particularly when BWS 106 and transaction 
server 110 are connected over an extranet 129, other end users at remote locations may 
couple to the BWS 106 and TS 106 via the Internet 104. In this model, transaction 
server 1 1 0 is the in-house product. In this embodiment, the Internet 1 04 is used only to 
permit some end user 101 remote access to IWS or TS and BWS 106 on the intranet. 

15 Other than the nature of network connectivity, elements of the inventive system and 
method are as described herein above. 

With reference to FIG. 4, structure and method provide for a second business 
and operating model and method which are primarily directed to a non-repudiation 
server as the authentication, electronic signature (e-signature) and non-repudiation 

20 Application Service Provider (ASP) on the Internet with a trusted partner. In this 
model, the interaction between the end user 101 through device 102, the non- 
repudiation server 1 1 0 with its LDAP database 1 1 3 and user Credential database 1 1 5 or 
their equivalent, and BWS 106 typically occurs over the Internet 104. The transaction 
non-repudiation server is operated as a service to validate a transaction or interaction 

25 between the end user device 102 and BWS 106. Note in the FIG. 4 embodiment, that 
details of BWS 106, transaction server 110, and mobile device 102 are as already 
described and not repeated here. 

BNSE>OClD: <WO 0aoO753aAl J_> 



wo 03/007538 PCT/US02/23237 

-24- 

5 In another configuration, now described relative to FIG. 5, a Wireless Password 

Bank (WPB) is implemented using, for example, an EPOC (Symbian) based phone 
(such as for example but not limited to, a Nokia 9210 Communicator or Ericsson 
R380). A fingerprint sensor, scanner, or other capture add-on or build-in device with a 
respective Client Agent applet (for example a Java applet) and drivers is provided. A 
10 simple wireless server side Password Bank for WML Pages using, for example the 
X.509v3 private "bio" extensions (PBE) is also implemented. 

The wireless password (PWD) bank embodiment may conveniently utilize a 
cellular or other mobile telephone handset as the end user device 102. It may also 
utilize any other communication device, wired or wireless, that includes the features 
1 5 utilized by the inventive technique. For example, the cellular handset or phone will 
include a biometric sensor 151 (such as a fingerprint sensor, microphone, and/or 
camera) with sensor data processing software, hardware, and/or other means, and a 
browser, such as microbrowser plug-in 1 7 1 . The cellular phone communicates with a 
wireless receiver station 155, which in turn communicates to a wireless Internet gateway 
20 1 56 via available wired or wireless communication means. Wireless Internet gateway 
156 in turn couples through and inventive Wireless Password Filter 172 and from the 
Wireless Password Filter 172 via Internet 104 (or other means) to transaction server 
1 1 0 as well as possibly to other Internet or world wide web-based sites or locations 1 73. 
For example, the system may be configured to communicate with such companies or 
25 portals as eticket.com, Schwab.com, eTrade.com, MyYahoo, or the like. Connectivity of 
such other sites 1 73 may be intermittent and dynamically changing. A direct wired or 
wireless communication link may also optionally be provided between the Wireless 
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5 Password Filter 172 and the transaction server 110. The transaction server 110 
desirably includes a database (such as an LDAP database) storing user credential 
database, business data (such as XML documents), and transaction records. Typically, 
such database or databases are implied. Transaction server 110 may desirably also 
include a Password bank within the user credentials database. 

10 In this wireless Password Bank, the client side program or applet (such as for 

example, a Java applet executed by a microbrowser) is or includes a simple plug-in or 
Java applet for the Microbrowser of a cell or other wireless phone or radio that controls 
the client side of the biometric authentication process. The wireless Password Filter 
also includes a plug-in (or other application) into the Wireless Gateway that filters out 

IS usemame/password requests from content or other web sites and replaces them with 
biometric authentication. This replacement process is advantageous because users tend • 
to accumulate a lot of passwords for different sites and or services. Having to remember 
all of them, or even to type them in, is inconvenient. Simply storing the passwords on 
the device without some forai of protection (a meta-password) would be a security risk. 

20 Therefore, releasing the stored passwords must be protected somehow, and in 
embodiments of the present invention passwords are protected with a biometric match 
of some sort (for example, using fingeq>rint biometrics). Note that in this embodiment, 
the passwords are stored on the transaction server 110, but they could also be stored on 
the client device 1 02 itself, which provides strong protection if secure storage exists that 

25 can only be unlocked by a biometric (such as for example, a smartcard or other 
securable memory device). After successful biometric authentication the filter 172 
retrieves the usemame/password for the requested web site from the transaction server 
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5 1 10 and returns it to the web site server. The transaction server 1 10 provides the 
biometric authentication service for the wireless Password Filter as well as a server side 
password wallet where the various user name/password couplets are stored. 

An exemplary embodiment of the transaction flow procedure 160 for the 
Wireless BioPDA™ embodiment is now described relative to nG. 6. First, a user 101 

1 0 indicates a desire to access a particular password-protected web site or portal, such as 
myyahoo.com (step 201) by directing the microbrowser to that particular web site or 
portal universal reference locator (URL). This request is directed to the myyahoo.com 
target site 173 from the microbrowser on the access device 102, through a wireless 
receiver station 155, wireless Internet gateway 156, and wireless password filter 172. 

15 Upon receipt of the request for access, the target site (such as for example, 
"myyahoo.com") 173, requests (step 202) usemame 193 and password 194 (or other 
sufficient identification) from the device 102 microbrowser. This request transits 
wireless password filter 172 and results in the initiation of execution (step 203) of the 
client agent applet 154. Execution of applet 154 results in the applet collecting and 

20 authenticating biometric information from the user 101 of the device 102 in conjunction 
with the transaction server. Once that biometric authentication has occurred, the 
transaction server, typically via an SSL or otherwise encrypted link, sends the usemame 
and password couplet information to the client agent 154. The client agent then 
supplies this information to the client microbrowser, and the client microbrowser in turn 

25 supplies this data to the originating website 106, 1 73 as if the user 101 had actually 
typed in the data them self Execution of the applet 1 54 ultimately results in biometric 
capture (such as a fingerprint scan) which is used for a local biometric match (step 
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5 203B). 

Once a local biometric match has been accomplished, the challenge/response 
authentication procedure (step 204) is performed between the client agent applet 154 
executing on the client device 102 and the transaction server 110. This 
challenge/response authentication procedure may result in either a positive 

10 (confirmation of identity) authentication result or a negative (denial of identity) 
authentication result. When the challenge/response authentication procedure results in a 
positive authentication result, the transaction server sends a signed 
authentication/transaction token 157, in one embodiment in the form of a stored 
usemame and password information, to the client device (step 205). The client device 

15 and applet then decrypts it, sends the usemame/password to the client microbrowser, 
which in turn forwards it back through wireless Internet gateway 156 and back to the 
website that requested the information in the first place (step 206). No token need be 
sent back to the originating website. 

Certain technical problems are overcome in the above described Wireless PWD 

20 Bank embodiment. For example, with respect to the client microbrowser, one 
embodiment provides or includes a client agent applet for an EPOC (Symbian) based 
browser that can communicate with the wireless password filter. An EPOC based 
browser is a browser that runs in a wireless phone and supports Java. The use of EPOC 
is advantageous at the present time as it supports Java and provides a documented SDK 

25 and architecture. Any of a built-in or external microphone, digital camera, or other 
biometric sensor or capture device, such as a fingerprint or other bioscanner may be 
added to device 1 02, such as for example by using a Multi-Media Card slot (Nokia 92 1 0 
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5 phone), PC card slot, compact flash card slot, or other custom configuration. Wireless 
password filter is provided to filter and identify incoming HTML (or other identified 
format) usemame/password requests. A proxy, such as an HTML proxy server, may 
alternatively be implemented to provide this functionality. Also, in one embodiment the 
transaction server 1 1 0 includes a server component that provides the bioauthentication 

10 service as well as a user credential database and transaction logging within an LDAP 
compliant or other database. However, other browsers or user interfaces may readily be 
used instead. With respect to phone or handset hardware and operating system (or 
equivalent control), drivers are provided for EPOC that talk to the bioscanner or other 
biometric capture device and are accessible fi^om the browser application. 

15 Embodiments of the inventive system and method provide numerous 

advantageous features; including certain hardware, architectural, system, and server- 
side, client-side, and system software/firmware. 

With respect to hardware features, for example, aspects of the invention 
provides a user device 102 having a rugged and low-cost (projected cost at about $5 or 

20 less per unit) silicon swipe fingerprint sensor suitable for mobile phone handset 
integration and the handset having such integrated (or add on or modular) sensor. In 
another aspect, the invention provides a rugged low cost printed circuit board (PCB) 
based finger print sensor that may readily be integrated into a mobile telephone, PDA, 
or other hand-held and/or portable wireless information appliance or device 102. 

25 Alternative embodiments provide support other than printed circuit board 
implementations, such as for example, a silicon substrate based swipe sensor. 

While the above described biometric sensor hardware implementation has 
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5 considerable utility and provides advantageous features and capabilities, it will be 
appreciated that embodiments of the inventive system, method, and computer program 
and computer program product are not dependent upon any particular device 102 or 
biometric capture device or hardware within or attached to the device 102. The 
invention may be used with any off-the-shelf biometric sensor, such as those provided 

1 0 by Authentec, Identix, and Infineon, as well as others. 

Where the biometric capture device is a fmgeiprint sensor, one embodiment of a 
finger print sensor is implemented as a silicon sensor involving a capacitive silicon 
swipe sensor technology. . This type of sensor provides the technological basis for high 
reliability as well as low^urrent and low-power consumption of it and its associated 

1 5 electronics. One embodiment generates a two-dimensional (2D) fingeiprint image (or 
features extracted fi:*om the equivalent image) from a one-dimensional sensor. Using a 
one-dimensional sensor therefore permits the sensor to occupy a very small footprint, an 
advantageous feature given the small size of mobile phones and PDAs on which such 
sensor may be placed. 

20 In one embodiment, the PCB based sensor is rugged and is integrated with the 

host device (e.g. mobile phone or PDA) very simply, as the PCB can be molded to 
conform to a desired shape. Inventive sensor electronics and sensor segment topology 
are a further aspect of the invention. Aspects of fingerprint (or other biometric) capture, 
reconstruction, matching and/or other software and/or firmware related processing are 

25 described herein elsewhere. 

In another aspect, the invention provides client-side software/firmware having 
advantageous characteristics for a portable thin client device such as a mobile phone or 
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5 PDA. These characteristics include high-performance small footprint (small size) 
fingerprint extraction, matching, or other processing algorithms that may be stored 
within memory size constraints (size and cost) of cellular phones and execute within a 
processor of the device without undue processor requirements or burden on other 
processor loading. In at least one embodiment, the invention provides for fingerprint 
1 0 (or other biometric) matching on Subscriber Information Module (SIM), a technique 
referred to here as "Match-On-SIM." In another aspect, the invention provides a novel 
transaction non-repudiation applet as described above. 

On the server and system side, embodiments of the invention provide non- 
repudiation server software and/or firmware. In another aspect, the invention 
1 5 implements biocertification methods and procedures. In a further aspect, the invention 
provides transaction non-repudiation software/firmware on the server side. 

In conjunction with the use of a one-dimensional fingerprint sensor, a procedure 
which is conveniently implemented as a computer program executing in the processor 
and associated memory of the host device 102 is used to either construct a two- 
20 dimensional finger print from the (in effect a plurality of sequential) one-dimensional 
scans, or to extract the fingeiprint features, commonly referred to as minutia, from the 
plurality of one dimensional scans without actually constructing the two-dimensional 
scan first. This later approach saves memory, and embodiments of the invention also 
save computations associated with reconstruction of the two-dimensional image and 
25 later recognizing the features, only to discard the raw two-dimensional scan. These 
techniques are referred to as the fingerprint or image reconstruction algorithm. 
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5 In another aspect, the invention provides fingerprint matching on the mobile 

device 102. Small, compact, or thin algorithms having sufficiently small amount of 
computer code and algorithms adapted for execution within the modest processor and 
memory capabilities (and cost) of typical mobile devices, particular cellular phone 
handsets. Recall that many non-repudiation transaction will involve fmancial 

10 transactions, such as purchases of goods or services, and financial investments such as 
the trading of stocks or bonds. Such transactions are made by mobile professionals and 
are most easily made using multi-purpose cellular telephones at a first level, and using 
PDAs and other mobile computing devices at a somewhat higher level. 

In one embodiment, the fingerprint matching algorithm software resides in less 

15 than 50 Kbytes of ROM or RAM and has low computational requirements. In one 
embodiment, the fingerprint matching algorithm is operative to perform a Match-on- . 
SIM. Match on SIM refers to having the biometric matching algorithm running on the 
CPU of the SIM card itself. This allows the SIM card to be used as a secure storage 
mechanism. SIMs have a small CPU and some user read/writable memory. This 

20 memory is typically unlocked (made available to the SIM's host hardware, such as the 
cell phone) through the use of a Person Identification Number (PIN) typed in the by 
user. In a Match-on-SIM card, instead of typing the PIN, the user can use his/her 
biometric data instead. The client agent applet would prompt the user to, for instance, 
place hisAier finger on the fingerprint sensor. The biometric data would then be sent into 

25 the SIM to be authenticated. If the SIM indeed authenticates the user's biometric data, 
then the SIM can unlock its secure memory area and allow it to be read from and written 
to by the cell phone's application software. This eliminates the inconvenience of user's 
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typing in a PIN, and in addition, provides secure storage for user credentials (as in the 
password bank described above) or private keys or any other secrets. 

In another aspect, the Non-Repudiation Applet embodies an elegant solution to 
client and user authentication that desirably use a Java security memory model, is 
downloadable and ungradable. portable, and easily integrated into a merchant's or 
other's web pages. An open application program interface (open API) is desirably 
provided so that third-party biometrics providers can plug-n-play. 

In still another aspect, the invention provides voice or speech recognition and 
matching. This is optionally but desirably provided on a SIM within the device to 
provide a Voice Match-on-SIM in addition to or instead of the Fingerprint Match-on- 
SIM. Hashing algorithms are desirably utilized to enable database privacy and security 

for any biometric data. 

Further aspects of some of the optional technology that may beneficially be 
applied to the inventive system and method are now described. Biocertificates are one 
particularly significant aspect of certain embodiments of the invention, though not of 
other aspects. In one embodiment, the Biocertificates are based at least in part on the 
standani Internet X.509 Version 3 (X.509v3) Public Key Infrastructure Certificates and 
related protocol promulgated in 1996. Internet X.509 PKI generally is an evolving 
standard known in the art. References to this standard refer to the versions existent in 
June 2001, for example CCITT Recommendation X.509 (1988), "The Directory - 
Authentication Framework" as well as IETF RFC 1422. The Biocertificates may be 
embedded as private extensions or attached as attribute certificates to the standard 
X.509 ID certificates. The private extensions and/or attribute certificates may similarly 
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5 be applied to other standard or non-standard certificates other than X.509 certificates 
and such X.509 certificates are described only by way of example not by way of 
limitation. 

In one embodiment described with reference to FIG. 7, it is assumed that the 
X.509 based certificate 240 includes several fields or components however organized, 

1 0 including: Version 24 1 , Certificate Serial Number 242, Signature Algorithm Identifier 
243, Issuer Name 244, Validity Period 245, Subject Name 246, Subject Public Key 
Information 247, Issuer Unique Identifier 248, and Subject Unique Identifier 249. An 
extensions filed or component is also peraiitted within the X.509 certificate and may 
normally be empty or contain other than the inventive bioextensions. These standard 

1 5 fields are known in the art, available firom the published standards, and not described in 
further detail here. 

When the Biocertificate is embedded as a private extension in the extensions 
field 250, one embodiment of the private extension provides the following fields or 
components: Enrollment Trust Level 251, Protection Trust Level 252, Common Bio 

20 Header Field 253, and an encryption {Encr. (Keypub ICTS) [Template]} 254, 
"Template" 254c is the extracted biometric information such as the fingerprint minutia 
used for fingerprint comparison and matching. 

Private Bio Extensions (PBEs) have certain advantages and disadvantages. 
Advantageously, they provide all necessary information in one certificate; since the 

25 extensions are non-critical to some applications, the PBE information can be ignored by 
those applications that do not need it or do not know about it; acceptance for X.509v3 
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5 private extensions is well established; and standard Certificate Authorities and 
Revocation Lists and structures can be used. 

Disadvantageously, all information in the X.509 certificate is meant to be public, 
and it follows that any attribute placed in an X.509 certificate cannot be kept 
confidential unless other measures are taken. Furthermore, the information in the 
10 certificate is tied to the life span of the certificate itself Finally, the Biometric 
information has to be available during registration, and existing certificates can be 
problematic for certain of the applications. 

Rather than PBEs. BioAttribute Certificates (BAC) 258 includes an ID 
certificate 259 and an attribute certificate 260 and may alternatively be used and are 
1 5 now described relative to FIG. 8. In one embodiment, the BioAttribute certificate 260 is 
an X.509-based Attribute certificate. One exemplary embodiment links the ID 
Certificate 259 Serial Number 262 of the X.509 ID certificate with the Holder 272 of 
the Attribute certificate 260. The Attribute certificate 260 includes fields or components 
for Version 271, Holder 272, Certificate Issuer 273. Algorithm Identifier 274, 
20 Certificate Serial Number 275, Validity Period 276. Enrollment Trust Level 277. 
Protection Tmst Level 278, Common Bio Header Field 279. and Encr. (Keypub ICTS) 
[Template] 280. 

As with the use of PBEs 240. the use of BACs 258 has advantages and 
disadvantages. For example, advantageously, the BACs 258 works with existing 
25 certificates so that no re-issue certificate is necessary. The content can be encrypted. 
The attribute certificate can be signed by the ICTS server. Applications that are not 
aware or don't want to use BAC 258 can use the original X.509 (for example, to 
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S increase speed). The Lifetime of the attribute certificate can be different than base 
certificate. 

Disadvantageously for the use of BACs, two signatures have to be created, the 
X.509 ED certificate 259 and the X.509 Attribute certificate 260. In order to perform the 
bioauthentication signatures have to be verified which increases complexity and 

10 processing time. Finally, attribute certificate are usually used for short-lifetime 
information, such as for example, for authorization information. 

While X.509 based certificates are described by way of example of the types of 
certificate or certificate information that may be used, it will be understood that other 
forms of biometric containing certificate may be used. Any file, data structure, date, 

15 code or other instrument containing a wrapped biometric, that is a combination of 
biometric data and a public key that is part of a public/private key pair used for 
encryption, decryption and cryptographic signing, may be used. 

An embodiment of a transaction token 320 is now described relative to FIG. 9. 
Upon successful authentication and/or signing of the transaction, the transaction server 

20 system generates a unique transaction token 320 that is passed back to the Server Agent 
107 on the Business Web Server 106. The Business Web Server 106 stores this token 
320 within it's own transaction log. In addition, the transaction token 320 can be used 
to access (request) the document or other content, such as an XML document, for that 
particular Business Web Server 106 and user 101 that the system maintains. An 

25 exemplary embodiment of the format and content of a Transaction Token 320 is now 
described. 

The exemplary transaction token 320 includes a globally unique Transaction ID 
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5 332 that is used to reference a transaction on all of the involved sides (servers and with 
client). In one embodiment, the Transaction ID 322 includes: (a) a time or time stamp 
323, where the time is advantageously an absolute time such as GMT (rather than a 
local time) and of high resolution; (b) a task or process identifier (PID) 324; (c) a 
machine or server identifier (Server Name) 325; and (d) a user identifier (User ID) 326. 
10 In one embodiment, transaction ID do not expire, such as when a communication 
connection is dropped or lost, so that audit requirements may be maintained. 

In one embodiment, a logging and auditing mechanism and record takes place on 
the transaction server 1 10, including a transaction log recording what happened with a 
created transaction token 320. This transaction token 320 is, in one embodiment, a 
15 subset of transaction record 310. The transaction record 310 includes: (i) a Transaction 
ID 322 in the transaction token 320, (ii) Business Web Server name 327, (iii)TCTS or 
transaction server name 328, (iv) Transaction Data 329 (optional depending on Business 
Web Server Policy: clear text, hash, encrypted with Business Web Server public key or 
void), (v) Time Stamp (e.g. GMT) 323 within transaction token 320, (vi) Security 
20 policy required by Business Web Server 330, (vii) Security policy used 331, (viii) 
Common biometric header format (CBEFF) 332, (ix) Used biometric template 333, (x) 
User ID (ICTS or transaction server user ID) 334, (xi) Certificate Serial number 335, 
(xii) Attribute Cert Serial number 336, (xiii) Signature format (used hash or the like) 
337, (xiv) Hash of transaction data 338, (xv) Signed hash of the above 339. It will be 
25 appreciated that not all of these items or fields in the record are required in all 
embodiments and that some are optionally but advantageously provided. 
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5 The data contained in the Transaction Token 320 can be configured as a policy 

setting per Business Web Server 106 and may be different for different policies and/or 
for different Business Web Servers, and is equal to, or a subset of, the data stored in the 
transaction record 310. While not representing a minimum configuration, the following 
default setting and contents or items may be used: Transaction ID 322, Security policy 

10 required by Business Web Server 330, Security policy used 331, User ID (ICTS or 
transaction server user ID) 334, Time Stamp 323, Hash of Transaction Data 338, 
Signature format 337, and Signed hash of the above 339. 

An Authentication Token is used to confirm a successful transaction 
authentication. One embodiment of the authentication token includes the following 

1 5 fields or elements: Transaction ED, Security policy required by Business Web Server, 
Security policy used. User ID (ICTS or transaction server user ID), Time Stamp, . 
Requested resource (URL), Signature fomiat, and Signed hash of the above. Note that 
the authentication token may be considered to be a special type of transaction token 320, 
it has the URL requested as the "transaction data" 329, and the signature is the signature 

20 of the "transaction server" performing the authentication. 

An embodiment of the user enrollment process 410 is now described. In the 
exemplary embodiment now described, user 101 initiates the enrollment process via a 
dedicated page or "registration" button on the Business Web Server 106 where the 
Business Web Server may either adopt some default enrollment requirements or can 

25 define specific enrollment requirements. For example, specifying the type of biometric 
(finger print, face recognition, retinal scan, voice print, or other biometrics known in the 
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5 art), number of samples, type of enrollment (face-to-face, over-the-air self-enrollment, 
or the like) (Step 411). 

A trusted Client Agent program, such as an applet or ActiveX control, on the 
client device (such as a Compaq iPaq, Palm Pilot, Handspring, Sony Clie PDA or other 
intelligent device) - is initiated and its airollment function is started, where trust may 

10 be established using standard code signing technologies (Step 412). 

A SSL/TLS session between the client device browser and the ICTS or 
transaction server Biometric Registration Authority (BioILA) is established by using the 
ICTS/BioRA server's X.509 certificate (Step 413). The Client Agent requests the user's 
usemame and any additional information necessary for the generation of a certificate, 

1 5 such as the X.509 based Certificate (Step 414). An email address for example may be 
one of the required additional information items. Upon receipt of the request, the user 
fills out necessary information and submits the information; and the client device 
optionally perfomis local plausibility checks on the information, such as whether all 
required fields have been provided or where only numbers have been submitted where a 

20 number entry is required (Step 415). 

The Client Agent on the PDA generates the user's RS A key pair (for transaction 
non-repudiation purposes), compiles the necessary user information and sends the 
X.509 Certificate request (using for example a PKCS #10) to the BioRA (Step 416). 
A user's private key will be stored in local key store encrypted with a user 

25 specific password, and in a separate local table (local user table) a new entry will be 
added with the userlD and an MD 5 or SHA-1 hash of the users password (Step 41 7). 



pMsnnctn <wo 



03007S3BA1 I > 



wo 03/007538 PCT/US02/23237 

-39- 

5 After appropriate request handling on the BioRA, the BioRA forwards the X.509 

certificate request to external PKI CA, using for example PKCS #10 (Step 418). 

An entry is logged at the BioRA indicating the successful transmission or 
forwarding of the X.509 certificate request for user XXX (where XXX refers to a user 
identification) to certificate authority ZZZ (where ZZZ refers to a certificate authority 
1 0 identification) at the identified date and time (Step 4 1 9). The signed X.509 certifi.cate is 
received fi-om the (external) PKI certificate authority (Step 420). An entry is logged at 
BioRA indicating the successful receipt of the X.509 certificate for user XXX from 
certificate authority at ZZZ date and time (Step 421). 

The BioRA forwards the signed X,509 certificate to the client device and 
15 generates a log entry indicated that it forwarded the X.509 certificate to user XXX at 
date and time (Step 422). 

Through the Client Agent, the BioRA acquires the initial biometric template(s) 
in accordance with the enrollment policy (Step 423). The Client Agent's enrollment 
function then collects any necessary additional user data (that is not part of the standard 
20 X.509 certificate, such as for example a credit card number or other information) and 
together with the biometric template creates the system specific Attribute Certificate, 
such as an Attribute Certificate XML structure. In addition the user's biometric 
templates are stored unencrypted in the local user table (Step 424). 

On the client device, the user's biometric template or templates are then 
25 encrypted using the user's RSA public key (Step 425), for example according to the 
W3C "XML Encryption Requirements, W3C Working Draft, version of 2001-April-20, 
incorporated herein by reference 
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5 On the client device, the Attribute Certificate XML structure (See Step 424) is 

then digitally signed with the user's private key (See Step 416) following the IETF 
"XML-Signature Syntax and Processing", draft-ietf-xmldsig-core-08.txt, [XMLDigSig] 
procedures as a proof-of-possession of the PKI private key associated with the 
certificate, received fh>m the PKI CA (Step 426). 
10 The Client Agent submits the request (including the XML structure) for the 

inventive IControl BioAttribute Certificate to the BioRA, and a log entry for this 
request is generated on user's client device (Step 427). 

The BioRA on the ICTS or transaction server verifies the signature on the 
received signed BioAttribute Certificate XML document by using the users X.509 
15 certificate (Step 428). Next, the BioRA on the ICTS transaction server uses the ICTS 
RSA signing key to sign (or counter-sign) the users XML document including the 
encrypted biometric template, the additional user data (such as the enrollment attributes) 
as well as the user's signature of the XML document using for example the 
[XMLDigSig] to generate the user's system IControl BioAttribute Certificate 
20 (Step 429). The IControl BioAttribute Certificate is stored in a ICTS directory and then 
sent back to the user's device for subsequent use in transaction signing processes 
(Step 430). 

On the BioRA of the ICTS, the completion of the generation of the user's 
IControl BioAttribute Certificate is logged (Step 431), and on the client device orPDA, 
25 the user is provided with feedback (such as a message) regarding the successfiil 
generation of his BioAttribute Certificate, and a respective local log entry is created 
(Step 432). 
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5 An exemplary embodiment of the Transaction Signing process, which in some 

embodiments includes the client-side biometric match, is now described. Transaction 
signing using Public-Key Infrastructure (PKI) requires the establishment of the signer's 
public key credential, the PKI certificate. The introduction of biometrics to the process 
is largely for enhancing the identification of the signer, before the signer utilizes their 

10 PKI private key to digitally sign a transaction. An additional value in the use of 
biometrics is that of providing a secure, convenient-user experience. 

The typical PKI user must input a Personal Identification Number (PIN) to the 
computing station, user device, or information appliance that contains the signer's PKI 
private key before the signer can use the private key to apply their digital signature. In 

1 5 many cases this PIN is used as an encryption agent in protecting the signer's PKI private 
key. It is conceivable that a PKI private key protection agent on the signer's computing 
station could acquire the user biometric information (BioID), evaluate this BioID 
against a BioID enrollment template, and allow use of the protected PKI private key to 
generate a digital signature or establish a secure communications channel. 

20 A security difficulty lies in the full-time protection of the PKI private key in a 

generally, unsecured computing environment. The quality of a security process to 
protect this key is often measured by three factors: (i) something you have (such as the 
computing station or device that contains the PKI private key); (ii) something you know 
(such as a PIN that is used to cryptographically lock the PKI private key); and (iii) 

25 something or someone you are (such as the biometric infomiation used to apply the 
above PIN to unlock the PKI private key). 
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5 While requiring the entiy of a PIN each time the PKI private key is required for 

use is considered good security, it's being acquired for each use is not considered a 
secure, convenient user experience. This is especially true if the signer's computing 
station is not ergonomically designed for convenient entry of the PIN, such as may be 
the case for a typical cell phone or PDA. Enhancing the user's experience along with an 
10 understood acceptable level-of-risk encourages the relaxation on requiring the PIN for 
every PKI private key use. Therefore embodiment of the invention that require PIN 
entry for every PKI private key use and embodiments that do not so require PIN entry 
for every PKI private key use are contemplated by the invention. 

From a convenience perspective not ever requiring the PIN is most appealing. 
15 Using the BioID value to "unlock" the PKI private key would provide an agreeable 
level-of-risk. This is particularly appealing ifthe PKI private key is generally protected 
from prying eyes on the signer's computing station. Specialized computing stations, 
such as smart cards or subscriber identity module (SIM), do not allow any external 
access to the PKI private key. Such is not the case in a general-purpose computing 
20 station. 

Software cryptographic protection of the PKI private key is used to minimize the 
window of opportunity to externally acquire the PKI private key. Ifthe BioID were 
deterministic rather than probabilistic in value, then the BioID could be used as the 
cryptographic key to lock access to the PKI private key. Such is not the case. Eitherthe 
25 PKI private key will need to be embedded in the BioID evaluation software with the 
acceptable level-of-risk being the unlikelihood that the compiled evaluation software 
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5 will be acquired and decoded for unacceptable use; or, the PKI private key must be 
cryptographically encoded by other means with an acceptable level-of-risk. 

The structures and methods described herein, including the use of the transaction 
token, provide procedures having an acceptable level-of-risk for many transaction 
environments, and also possessing appealing user-convenience characteristics. 

10 It is noted that in some of the embodiments described herein, it is assumed that 

no secure storage such as a smart-card based SIM exists in the system, so that a 
password is needed to decrypt or unencrypt the stored secrets. If secure storage does 
exist, however, then all the secrets (such as passwords and/or private keys) can be stored 
using the secure storage and unlocked with a biometric match. Provision of the smart- 

15 card, SIM, or other protectable or secure storage, also permits the so called match-on- 
SIM or match-on-smart-card functionality. 

Other Exemplary Aspects and Features 

Aspects of the invention provide true transaction non-repudiation on a wireless 
20 device and ensure that both the sender and the receiver are who they say they are and 

facilitate creation and operation of an insurable wireless transaction. 

At a top level, the inventive system, method, and computer program produce 

software enables confident, trusted, electronic and mobile commerce (mCommerce). 

Convenience is facilitated by permitting customers to create and log-in to personal 
25 accounts without cumbersome Personal identification numbers or codes (PINs) and 

passwords. This feature encourages increased usage and new subscribers. The 

invention also provides transaction non-repudiation so that service providers and 
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5 merchants capture proof-positive transaction audit trails that mitigate repudiation risk. 
Privacy is enhanced so that customers gain confidence in the confidentiality of their 
transactions, thereby encouraging increased usage and new subscribers. Security is 
provided at a level that customers gain trust in the security of their personal accounts 
and personal information, again encouraging increased usage and new subscribers. 

1 0 The invention permits and supports authentication at any one or more of several 

levels using a variety of authentication options. These options include but are not 
limited to passwords, tokens, smart cards, digital certificates, and biometrics. 
Biometrics includes but is not Umited to fingerprint or fingerprint derived biometrics, 
retinal imaged or scanned biometrics, voice or speech based biometrics, molecule based 

1 5 Biometrics, or other biometric or biometrically derived data. 

The authentication options are or may be combined with any one or more of 
available devices, particulariy mobile devices such as mobile or cell phones, PDA's, 
hybrid PDA and mobile phones, and personal computers (PCs) or other information 
appliances. 

20 It is noted that the inventive system and method have numerous advantages over 

conventional systems and methods. These advantages may include one, more, or all in 
any particular embodiment, but are not limited to: (i) multiple levels of authentication 
from moderate (passwords) to strong (digital certificates) to very strong (biometrics); 
(ii) flexible, layered authentication alternatives; (iii) vendor independence for 

25 authentication methods and devices; (iv) client-side applet is device independent (for 
example Java-based client-side applet); (v) powerful, back-end authentication web 
server, (vi) highly scalable to millions of users; (vii) easily deployed and integrated to 
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5 existing Web applications; and (viii) can be deployed either as a licensed product and as 
a serN'ice. 

From the standpoint of a business model and method, deployment and/or 
operation of aspects and embodiments of the invention may provide for deployment as a 
licensed product or as an out-sourced service. When deployed as a licensed product, 

10 customers may for example, license the client side products on a per user basis along 
with the server software. License produce may alternatively license the products on a 
per week, per month, annual, or on any other time-based, transaction-based, percentage 
of transaction amount based, or other basis. 

When deployed as an out-sourced service, aspects and embodiments of the 

15 inventive system and method provide an authentication, e-signature and transaction 
non-repudiation service on the tatemet or over any other public or private network. 

The foregoing description, for purposes of explanation, used specific 
nomenclature to provide a thorough understanding of the invention. However, it will be 
apparent to one skilled in the art in light of the description provided that the specific 

20 details are not required in order to practice the invention. Thus, the foregoing 
descriptions of specific embodiments of the present invention are presented for purposes 
of illustration and description. They are not intended to be exhaustive or to limit the 
invention to the precise forms disclosed, obviously many modifications and variations 
are possible in view of the above teachings. The embodiments were chosen and 

25 described in order to best explain the principles of the invention and its practical 
applications, to thereby enable others skilled in the art to best utilize the invention and 
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5 various embodiments with various modifications as are suited to the particular use 
contemplated. 



10 
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5 We Claim : 

1 . A transaction authentication and non-repudiation system comprising: 

a transaction server intermittently coupleable to other information 
processing devices over a network; 

said transaction server including or coupleable to a database storing at least 
10 one user credential and at least one transaction record; 

said transaction server including a processor and a memory coupled to said 
processor for executing transaction authentication instructions. 

2. The system in claim 1, wherein said transaction authentication instructions 
1 S include instructions for a challenge/response authentication. 

3. The system in claim 2, wherein said transaction authentication instructions 
include instructions for sending a signed authentication/transaction token. 

20 4. The system in claim 3, wherein said sent signed authentication/transaction token 

is sent to an external client agent computer program executing in processor and 
coupled memory in an external client device. 

5. The system in claim 4, wherein said external client device comprises a wireless device. 

25 
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5 6. The system in claim 3, wherein said .transaction authentication instructions 

include instructions for communicating with a server agent computer program on an ■ 
external business/merchant web server. 

7. The system in claim 1, wherein said at least one user credential comprises a 
1 0 plurality of user credentials. 

8. The system in claim 1 , wherein said at least one transaction record comprises a 
plurality of transaction records. 

15 9. The system in claim 1 , wherein said at least one user credential comprises at least 

one of a biocertificate, a certificate chain, a merchant data, and combinations 
thereof. 

1 0. The system in claim 1 , wherein said transaction server includes or is coupleable 
20 to a biometric registration authority. 

11. The system in claim 10, wherein said biometric registration authority comprises 
an X.509v3-based certificate authority. 

25 12. The system in claim 1 0, wherein said biometric registration authority comprises 

an X.509v3 certificate revocation list. 
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5 13. The system in claim 10, wherein said network comprises a global network of 

interconnected computers and information appliances. 



14. The system in claim 13, wherein said global network of interconnected 
computers and information appliances comprises the Internet. 

10 

15. The system in claim 1, wherein said other information processing devices 
include a client device. 

16. The system in claim 1, wherein said other information processing devices 
1 5 include a business/merchant web server. 

17. The system in claim 1, wherein said other information processing devices 
include a client device and a business/merchant web server. 



20 18. The system in claim 17, wherein said client device includes wireless 

communication means for communicating with said network. 

1 9. The system in claim 1 8, wherein said wireless communication means includes a 
radio- frequency communication modem for coupling to said network via a wireless 
25 network gateway. 
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20. The system in claim 19, wherein said wireless network gateway comprises a 
wireless Internet gateway. 



21. The system in claim 18, wherein communications over said network are 
conducted using WML. HTML. WAP/HTML, CHTML, xHTML. and 

1 0 combinations, subsets, or extensions thereof. 

22. The system in claim 17, wherein the client device includes a client agent for 
performing a local biometric matching. 

15 23. The system in claim 22, wherein said client device fiirther includes a biometric 

sampling component for obtaining a biometric sample from a user. 

24. The system in claim 23, wherein said biometric sample comprises a biometric 
sample selected from the set consisting or a fingerprint sample, a face image 

20 sample, a retinal scan sample, a voice sample, a genetic sample, and combinations 
thereof. 

25. The system in claim 17, wherein said business/merchant web server comprises 
a server agent. 

25 
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26. The system in claim 25, wherein said server agent is implemented as a 
computer program including computer program instructions executing on a 
processor and memory of said business web server. 



27. The system in claim 22, wherein said client agent is implemented as a computer 
10 program including computer program instructions executing on a processor and 

memory of said client device. 



28. The system in claim 1, wherein said transaction server includes a computer 
program including computer program instructions executing on a processor and 

1 5 memory of said transaction server. 

29. The system in claim 1 7, wherein said business/merchant web server includes or 
is coupleable to a banking infrastructure or entity. 

20 30. The system in claim 1 7, wherein said business/merchant web server includes or 

is coupleable to a financial transaction infrastructure or entity. 

3 1 . The system in claim 1 7, wherein said business/merchant web server includes or 
is coupleable to a stock, security, or bond purchase or sale transaction infrastructure 
25 or entity. 
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5 32. The system in claim 2 1 , wherein the communications over the network include 

communications built upon an underlying TCP/IP protocol. 

33. The system in claim 32, wherein the communications include a WAP/HTLM 
over TCP/IP protocol or improvement or extension thereof. 

10 
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